\documentclass{article}

\title{dDist Aflevering G1}

\author{The Shadow Dread Lord Master-Gods\\of the\\Dark Evil Dead Doom Legion\\ \\Jeppe Hansen 20061245\\Steffen Jensen 20061335\\Asger Feldthaus 20061089}

\newenvironment{code}{\begin{quote}\ttfamily}{\end{quote}}

\newcommand{\uri}[1]{\texttt{#1}}
\newcommand{\headerfield}[1]{\texttt{#1}}

\setlength{\parskip}{6 pt}

\begin{document}

\maketitle

\section{Task 1}
HTTP is based on the request/response-paradigm. A client sends a request to a server, and the server may send one response in return. The server cannot open a connection; only the client can do that.

It is built on top of the TCP-protocol, which ensures that packages arrive in the correct order, and sends packages repeatedly if they should get lost. 

An HTTP message has a header and a body part. The header part is always text-based, and assigns a number of header fields to values. For example, a request message may contain the header field,
\begin{code}
	Referer: http://www.google.com
\end{code}
indicates that the client was directed here from Google's website (not reliable, of course).

The first line of an HTTP request contains the request method, the requested URI, and HTTP version. For example, a request might begin with,
\begin{code}
	GET /welcome.html HTTP/1.0
\end{code}
indicating that we are requesting the file \uri{/welcome.html} from the server, using HTTP version 1.0.

Likewise, the first line of a well-known response might look like,
\begin{code}
	HTTP/1.0 404 File not found
\end{code}
indicating that the response is in HTTP 1.0, with response code 404.

The header and body are separated by a blank line. The body may contain anything, and its encoding is specified by the header "Content-Encoding".


\section{Task 2}
		
If two computers both act as server and client for each other, we can pass any information between these computers whenever we like, and any architectural style, system architecture, and distributed system type can be applied. We will therefore concentrate on the cases were any two connected computers are either server or client of the other.
		
\subsection{Transparency}
HTTP does not provide complete \textbf{access transparency}. Consider the header-field \headerfield{Content-Encoding}; it explicitly tells the recipent how the body of the message is represented.

HTTP inherits the \textbf{location transparency} from the TCP/IP protocol, which it builts upon, ie. the client does not need to know the physical address of the server, nor the resources it uses.

The HTTP protocol does not concern itself with what other users are doing, so how well \textbf{concurrency transparency} is achieved is up to the server.

\textbf{Migration} is not transparent in HTTP. Instead, using the response codes 301 or 302 (``Moved Permanently/Temporarily'') the server can explicitly tell the client that a resource has moved elsewhere. 

\textbf{Relocation transparency} does not make much sense for HTTP, because of the request-response paradigm. A file can hardly get relocated while the server is generating a response, and if it is, it is entirely up to the server to handle this properly.

HTTP inherits some \textbf{failure transparency} from the TCP protocol. For instance, TCP compensates for lost packets by sending them repeatedly.

\subsection{Distributed system types}
	
\textbf{Grid Computing System:}\\
		We can build a grid computing system using HTTP. Client computers request assignments from a server (collective layer) using HTTP (connectivity), and the server responds with all the data required to start the task (resource layer). The client starts solving the task locally (fabric layer). When it is done, it sends a request to the server using HTTP again, containing the results from the task. The application layer connects to the collective layer to review results using HTTP also.
	
\noindent\textbf{Cluster system types:}\\
		HTTP is not suited for this kind of system. The master node needs to start the compute nodes, but the compute nodes will also need to notify the master node when they are done. The compute nodes will also need to communicate, without a clear client/server relationship, which is not possible with HTTP.
	
\noindent\textbf{Transaction Processing Systems:}\\
		With the keep-alive header, an HTTP connection can stay alive for exactly one transaction. If the connection times out before the transaction terminates, the server can choose to abort the transaction. Keep-alive is somewhat unreliable in most implementations, but the protocol itself supports it.
		Alternatively, the server can respond with a "transaction ID" which the client can specify in subsequent requests to indicate that they belong to a specific transaction.
		It is up to the server implementation to maintain the ACID properties; that is not related to the protocol.

\noindent\textbf{Enterprise Application Integration:}\\
RPC and RMI can be built with HTTP, since call/return-paradigm of function calls corresponds nicely to the request/response-paradigm in HTTP. 
If each method call is made with a separate HTTP request, it should wait for the server to respond, even if it returns void. Otherwise, the connections might not arrive in the same order as they appear. For example:
\begin{code}
	list.clear();
	list.add(A);
\end{code}
If "list.clear" arrives before "list.add A" we would get nasty side effects. If we use HTTP Keep-Alive we might be able to optimize the performance of this.
	
	
	
	
\section{Architectural styles}
HTTP uses a \textbf{layered architecture}. It builts on top of TCP, which builts on top of IP.

\textbf{Event-based architecture} requires that the Event Bus can make requests to the components (event notification), and the components can make requests to the event bus (event publish). So we can't use HTTP to build an event-based architecture.
	
A \textbf{data-centric architectural style} can be built on top of HTTP, as we can request a resource, and the data reposiory does not need to make requests to the clients; only responds.
	
An \textbf{object-oriented architecture} can be built with HTTP, if we use one HTTP request for each method call, and the response contains the method's return value.
	

\section{System architecture}
	
The \textbf{centralized architecture} can be built using HTTP, since the server cannot respond without a preceding request, similar to the request/response-paradigm used in HTTP.
	
In a \textbf{structured peer-to-peer architecture}, any peer may send an HTTP request to the peer in possession of a particular data item. A peer can send an HTTP request to another peer when it needs a data item, which then sends the data item in the HTTP response.
		
	
		
		
		
		
		
		

\end{document}